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OFF-LINE REMOTE LOTTERY SYSTEM 
BACKGROUND 

The present invention relates generally to 
remote gaming systems, and more particularly, to a 
lottery system in which lottery games typically 
embodied in a ticket having multiple chances which 
represent a single outcome offered by a lottery 
authority are rendered on a gaming computer as an 
"electronic ticket," such as, for example, a 
dedicated hand-held device or programmed general 
personal computer, which enables a player to reveal 
the ticket outcome with the same convenience as 
typical paper scratch-off tickets at any location 
without the gaming computer ever having to be 
physically or electronically connected to a lottery 
system network during play, thereby providing 
enhanced play value for the player and greater 
revenues for the lottery authority. 

In one type of common prior art paper instant 
ticket system, a computer generates a randomized 
prize datastream comprised of a finite series of 
win/lose outcomes. Each outcome is assigned to a 
lottery ticket, and each ticket contains one or more 
game chances which yield the assigned outcome. The 
player cannot change the ticket outcome, he or she 
merely scratches off certain areas of the ticket in 
accordance with the rules of the game to reveal the 
outcome. The ticket contains indicia which provide 
the player with a means to determine win/lose 
results or prize status, and the type of prize 
(e.g., cash or a free ticket). The aggregate of all 
winning outcomes in any randomized prize datastream 
is a predetermined-, percentage payout of the total 
revenues that would be generated by the sale of all 
of the tickets incorporating that particular 
randomized prize datastream. 



wo 97/02074 



PCT/DS96/in56 



-2- 

Each ticket is assigned a unique ticket serial 
number for validation purposes which identifies that 
ticket with a specific outcome, and a batch number 
which links the ticket to a master carton in which 
groups of tickets are shipped to lottery retailers 
in specific quantities. The ticket serial number is 
usually concealed beneath the foil of the ticket. 
The batch number is typically visible on the ticket 
in the form of a bar code. All tickets in a given 
master carton are part of the same ticket lot and 
are sold at the same price point. Each master 
carton is labeled with a unique master carton serial 
number which is tracked by a central computer 
associated with the lottery authority. The central 
computer also stores every ticket serial number and 
the associated outcome for that ticket. When the 
instant tickets are to be sold to customers, the 
lottery retailer communicates the master carton 
serial number via his on-line agent terminal to the 
lottery central computer and thereby activates all 
of the paper instant tickets in each master carton. 
This action activates all of the ticket serial 
numbers in that master carton, and typically causes 
the lottery retailer's lottery bank account to be 
automatically debited for the wholesale cost of that 
master carton within a specified time period. 

To redeem a winning paper lottery ticket, the 
player presents the same to a redeeming agent, 
either at a lottery retailer or lottery office, or 
mails the ticket in for redemption. To effectuate 
the redemption process, the redeeming agent scans 
the bar code on the ticket which represents the 
batch serial number on the ticket through a bar code 
scanner associated with the agent terminal. The 
ticket agent also enters the ticket serial number 
into the agent terminal . These ticket serial 
numbers are transmitted to the central computer for 
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purposes of validation. When the central computer 
receives a validation request, it activates an 
on-line validation program which queries a ticket 
value database using the particular ticket and batch 
serial numbers to confirm that the ticket came from 
an activated master carton. If the ticket value 
database confirms a payout, the validation program 
authorizes the lottery retailer to pay the player 
cash or provide another prize (e.g., a free ticket). 

In other paper instant ticket systems, there is 
no lottery central computer which manages the 
system. The lottery retailer simply buys tickets 
from a printer, resells them to players, and then 
handles all aspects of validation and payment of 
winnings . 

Paper instant ticket systems suffer from 
several drawbacks. These include the costs of 
printing tickets, the physical inventory costs, the 
costs to the lottery authority and retailer 

20 associated with unsold tickets, the inability to 
effectively offer low-price games (e.g., $0,25, 
$0.10), the limited game choices for the player, and 
the stigma associated with paper tickets as 
appealing toward lower income players, among others, 

As an alternative to instant paper tickets, 
systems have been devised which replicate instant 
tickets on a computer terminal or gaming machine. An 
example is shown in U.S. Patent No. 5,324,035, which 
discloses an on-line video gaming system comprised 

30 of a plurality of slave terminals, a plurality of 
master processing units, and a central game 
processor. A plurality of slave terminals are 
networked to each master processing unit and all of 
the master processing units are networked to the 

35 central game processor. The central game processor 
downloads fixed pools of game plays to each master 
processing unit. The slave terminals request game 
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plays from the fixed pool in the master processing 
unit. The group of slave terminals coupled to a 
particular master processing unitdisplay indications 
of the chances of purchasing one of the remaining 
winning plays in that pool to provide an element of 
competition between players situated at the various 
slave terminals. Thus, players at each slave 
terminal may decide to wait for the odds of 
purchasing a winning play to increase by allowing 
other competitors to purchase some of the remaining 
non-winning plays. Although this system is capable 
of rendering instant paper- tickets in a video 
format, its primary drawback is that it is a 
networked on-line system. Every play (outcome) 
15 requested by the slave terminal must be downloaded 
on-line from the master processing unit. 
Accordingly, this system is limited in that players 
can only engage in lottery play at specified 
locations . 

Another on-line video gaming system is 
disclosed in U.S. Patent No, 4,652,998. This system 
comprises a plurality of remote terminals networked 
to a central controller which generates a prize pool 
based upon a pool seed which is fed to a random 
25 number generator. The central controller divides the 
prize pool into mini -pools, each of which has a 
known amount of low-end prize value (e.g., all 
prizes of $25 or less) . There are a selected number 
of larger prizes which are distributed among the 
mini -pools where some mini -pools have a large prize 
and some have none. Mini-pools are assigned to each 
terminal for each game which is rendered on the 
terminal as needed. The remote terminals have means 
for randomizing each mini -pool assigned to the 
35 terminal using a mini -pool seed provided by the 
central controller to feed a random number generator 
using a randomizing algorithm. When the central 



30 
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processor has assigned all mini-pools within a pool, 
the central processor creates a new pool. After 
players have played a sufficient number of games to 
exhaust an entire mini -pool at a given remote 
5 terminal, it connects to the central controller and 
is assigned a new mini-pool. This system also has 
significant limitations. Because the prize 
structure in the mini -pools is assigned to each 
remote terminal in a "dynamic state", i.e., the 

10 remote terminal is assigned active outcomes before a 
player engages in play, it is necessary to provide 
various security measures in the remote terminals to 
prevent an unscrupulous player from "looking ahead" 
by "hacking" the machine and determining the outcome 

15 sequence in any given mini-pool. Otherwise, a 
player might learn at what point in the mini -pool a 
large win will occur for the game being played and 
then wait to play until when a favorable outcome is 
due to occur. This characteristic thus makes such a 

20 system unsuitable for an off-line arrangement where 
players are free to purchase "tickets" and view the 
outcomes at any location. 

It is therefore desirable to provide an 
off-line system in which a player can enjoy games 

25 having a predefined outcome determined by a lottery 
authority or the like on a gaming device, without 
the need to be physically or electronically linked 
to a central computer associated with the lottery 
authority during play, where "ticket" purchase and 

3 0 redemption of winnings may be done at virtually any 
location, and where the lottery authority is not at 
risk of being cheated since there are no secrets 
stored in the device, 

SUMMARY OF THE INVENTION 

35 Accordingly, it is a primary object of the 

present invention to provide a lottery system 
whereby instant "tickets" or psuedo-choice games 
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with a predetermined outcome can be rendered on a 
gaming computer (the gaming computer may be any 
personal computer, personal digital assistant or the 
like, but will be referred to herein as a hand-held 
5 ticket viewer "HTV") to enable a player to 
participate in a lottery at any location as with 
instant paper tickets, all the while providing 
enhanced play value through computer simulation of 
games on the HTV, 

It is a further object of the present invention 
to provide a lottery system which allows for 
replicating outcomes on a HTV where the outcomes are 
stored in a record on a lottery central computer 
("LCC") with identification data for that HTV to 
15 eliminate the need for security in the HTV. 

It is yet another object of the present 
invention to provide a lottery system which enables 
outcomes to be replicated on an HTV and redemption 
at a lottery retailer with the same convenience as 
20 with instant paper tickets. 

It is a further object of the present invention 
to provide a lottery system which provides for the 
portability of outcome purchase and redemption 
through any interactive communications network such 
25 as the Internet or simply over the telephone. 

It is another object of the present invention 
to provide a lottery system which provides a lottery 
authority with increased sales and profits, more 
competitive entertainment alternatives and higher 
30 customer satisfaction. 

It is a further object of the present invention 
to provide a lottery system which eliminates 
printing costs, inventory costs and cash flow delays 
associated with instant paper tickets. 

It is a further object of the present invention 
to provide a lottery system which eliminates the 
disposal costs associated with paper instant tickets. 
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It is yet another object of the present 
invention to provide a lottery system in which an 
HTV provides for a longer play time than that 
possible with instant paper tickets. 

.5 It is yet another object of the present 

invention to provide a lottery system in which games 
rendered on an HTV may be provided in a large type 
option which generates larger game formats to make 
it easier for people with poor vision to play the 

10 games. 

It is another object of the present invention 
to provide a lottery system which allows for venue 
expansion through sales of instant ticket type games 
in venues where sales of paper tickets are 
15 impractical such as in restaurants and the like. 

It is still another object of the present 
invention to provide a lottery system in which game 
tutorials and help screens on a HTV enable players 
to learn new lottery games. 

It is yet another object of the present 
invention to provide a lottery system in which games 
are rendered on a HTV and the machine tells the 
player when he or she is a winner. 

It is a further object of the present invention 
25 to provide a lottery system in which new lottery 
games may be transferred to a HTV through a plug-in 
module . 

It is still another object of the present 
invention to provide a lottery system in which the 
JO lottery authority can inexpensively test new games 
and obtain user feedback by transferring new games 
for user sampling to a HTV through a plug-in module. 

It is yet another object of the present 
invention to provide a lottery system in which 
^5 advertising in connection with any lottery game may 
be transferred to and replicated on a HTV. 

It is a another object of the present invention 
to provide a lottery system in which games which are 
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races of skill such as crossword puzzles or word 
descrambler games which must be completed in a 
. certain period of time but which have a 
predetermined outcome are rendered on a HTV, 

5 It is a further object of the present invention 

toprovide a lottery system which increases lottery 
sales and player game value by providing for the 
reinvestment of winnings on a HTV. 

It is yet another object of the present 

0 invention to provide a lottery system which allows 
for a lottery authority to track players and their 
frequency of play on a database to provide bonus 
awards and incentives. 

It is still another object of the present 

5 invention to provide a lottery system which reduces 
player fatigue by enabling a player to select from a 
plurality of games on a HTV irrespective of the 
predetermined outcomes purchased from the lottery 
authority. 

0 It is a further object of the present invention 

to provide a lottery system which reduces ticket and 
validation costs for the lottery authority through 
electronic batching and reduced claim "events." 

It is another object of the present invention 

5 to provide a lottery system which makes instant 
ticket type lottery games attractive to a wider 
group of participants who enjoy playing games on 
machines and personal computers. 

It is a further object of the present invention 

0 to provide a lottery system in which a HTV may be 
enabled for play and disabled in accordance with its 
location using a Global Positioning System ("GPS") 
receiver . to facilitate in-flight gaming where the 
HTV may be prevented from operating unless it is 

5 located within a venue that allows for gaming. 

In accordance with the above objects and 
additional objects that will become apparent 
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hereinafter, the present invention in a first 
embodiment provides a remote off-line lottery system 
generally comprised of at least one HTV for 
revealing "tickets" (outcomes) purchased from a 
lottery or wagering authority ("lottery authority"); 
a LCC; and a telecommunications network which 
providesremote terminal access to the LCC from a 
plurality of agent terminals ("AT") located at 
various lottery retailers where the player can go to 
purchase outcomes and redeem winnings. 

The LCC contains software or firmware which 
generates a randomized prize datastream ("RPD") 
comprised of a finite series of win/lose outcomes. 
The aggregate of all winning outcomes in any RPD is 
a predetermined percentage payout of the total 
revenues to be generated by the sale of all of the 
outcomes in the RPD. The LCC stores a record of 
identification data in memory for registering a 
plurality of HTVs with the lottery authority and may 
store information with respect to individual players 
to allow for bonus awards and incentive programs. 

In the first embodiment, the player goes to a 
lottery retailer having an AT and requests to 
purchase m "tickets." The agent obtains 
identification information in the form of an outcome 
purchase request message OPRM from the HTV and 
enters it into the AT which communicates this 
information to the LCC where the HTV is verified as 
a properly registered unit. The agent then provides 
the number of outcomes requested m. The LCC randomly 
assigns the next m outcomes from the RPD and stores 
a record of the outcomes purchased with the 
identification data, for that HTV. Thus, the LCC 
knows exactly which HTV has been provided with which 
outcomes for future redemption of winnings . The LCC 
then generates an outcome transfer message OTM and 
communicates the same to the AT. The outcome 
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transfer message OTM may be printed out on a receipt 
at the AT and provided to the player for manual 
entry into the HTV, The outcome transfer message 
OTM may be rendered in the form of a bar code on the 
5 receipt to enable being scanning by a bar code 
scanner associated with the HTV. Alternatively, the 
outcome transfer message OTM may be written to data 
memory media such as a smart card with a read/write 
interface associated with the AT, where the HTV has 

10 an associated read/write interface for reading the 
outcome transfer message OTM from the smart card. In 
yet another embodiment , the AT and the HTV both 
include means for physically coupling the HTV to the 
AT to enable the HTV to directly read the outcome 

15 transfer message OTM from the AT. In still another 
embodiment, the outcome transfer message OTM may be 
spoken into a microphone in the HTV where the HTV 
has voice activated circuitry for reading the 
message. Further embodiments described below in 

20 which there is no AT required, include a telephone 
•.embodiment, where the player obtains the outcome 
transfer message OTM over the telephone and then 
manually enters it into the HTV, or where the HTV 
includes a modem for obtaining the outcome transfer 

25 message OTM directly over a telephone line. In still 
another embodiment, the HTV may include a 
transceiver for receiving an outcome transfer 
message which is broadcast through RF communications 
between a base station associated with the LCC and 

30 the HTV. 

The HTV contains software or firmware which 
enables it to generate games which reveal the 
purchased outcomes represented in the outcome 
transfer message OTM. The games may be updated in 

35 the HTV by transferring new game programs to the HTV 
via a smart card or the like. The software also 
allows for the generation of games for practice 
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• sessions or tutorials for the games to teach players 
how to play. The games reveal the predetermined 
outcomes and may be "no-choice" as with instant 
paper tickets, bingo games or a sweepstakes; or 
5 psuedo-choice (e.g., video poker with a 
predetermined outcome if the player plays every hand 
correctly) . The outcome transfer message OTM may 
represent the outcomes selected from the RPD in a 
compressed sequence. This enables a simple codeto be 
10 printed on a receipt for manual entry or bar code 
scanning. In another embodiment, a reference string 
HTVRS containing a very large series of random 
outcomes is identically stored in both the LCC and 
the HTV. The outcome transfer message OTM represents 
15 an address or addresses in the HTVRS which contain a 
sequence of outcomes that either identically match 
those outcomes selected from the RPD or the net 
payoff on those selected outcomes. In another 
embodiment, both the LCC and the HTV store a one-way 
algorithm for generating outcomes in response to a 
seed value. The seed value is selected by the LCC to 
generate the outcome sequence from the RPD. The 
outcome transfer message OTM represents this seed 
value. Once the HTV is provided with the outcome 
25 transfer message OTM by any of the above methods, it 
generates games which yield the outcomes or the net 
payoff on those outcomes. 

To prevent an outcome transfer message OTM from 
being used in the wrong HTV, the outcome transfer 
message OTM may be encrypted by the LCC using keys 
known only to the LCC and a particular HTV for 
decryption in that HTV. Similarly, the outcome 
transfer message OTM may include message 
authentication codes which are verified at the HTV 
using keys known only to the LCC and that HTV. The 
LCC and the HTV may store a chaining variable for 
the particular HTV which is updated as a one-way 



20 



30 



35 
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function of all outcomes that have been purchased or 
played by that HTV. The chaining variable is updated 
•by the LCC every time an outcome purchase is made 
and by the HTV every time the HTV receives a new 
5 outcome transfer message. The chaining variable may 
then be used to generate a new OPRM every time an 
outcome purchase request is made to the LCC, and/or 
as an encryption or message authentication key. 

In one embodiment, additional outcomes are 

10 providedto allow for player reinvestment. These 
outcomes are referred to herein as "standby 
outcomes." Thus, a given outcome purchase for m 
outcomes may include x standbyoutcomes which enable 
the player to reinvest winnings on the m purchased 

15 outcomes. The number of standby outcomes included in 
a given purchase may be selected so as to eventually 
provide for total exhaustion of winnings or a large 
prize above some predetermined threshold by the 
lottery authority. This will be explained in more 

20 detail below. 

As the HTV generates games which reveal the 
outcomes, the cash balance is updated in an account 
stored in the HTV. The LCC Similarly knows the net 
pay-off for a given purchase. When the player seeks 

25 to cash out, he or she either provides the agent at 
the AT with a redemption request message RRM or 
communicates the redemption request message RRM 
directly to the AT using any of the methods 
described above with respect to the outcome transfer 

30 message OTM. The AT transmits the redemption request 
message RRM to the LCC, which verifies the identity 
of the HTV and the expected payout for that HTV, If 
standby outcomes were assigned, the redemption 
request message RRM includes a representation of 

35 which standby outcomes were revealed by the HTV, Any 
standby outcomes which were not revealed are voided 
as part of the redemption process. The player is 
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then paid by the lottery retailer, or if the prize 
has significant monetary value, the player may be 
required to send in a form for subsequent payment 
from the lottery authority. 

In one alternative embodiment, the LCC is 
coupled to a telecommunications network having 
interactive voice capability and is accessible by 
dialing a 900 number or the like to enable the 
outcome purchase and redemption to be effectuated 
over the telephone. The player simply keys the 
information into the telephone in response to 
prompts from the system. Thus, the player first 
communicates the HTV identification information to 
the LCC. If HTV identification is confirmed, the LCC 
then provides a "ready" indication to the player 
with instructions to select the number of outcomes 
to be purchased for each price point . The LCC then 
generates an outcome transfer message OTM as 
described above which the player manually keys into 
the HTV. The system operates Similarly to redeem 
winnings. The HTV generates a redemption request 
message RRM, and the player keys the redemption 
request message into the telephone. The redemption 
request message RRM is communicated to the LCC, 
which verifies the identity of the HTV and the 
expected payoff. A credit is then made to an account 
for the HTV/player in the LCC, In a modification of 
this embodiment, the HTV contains a modem which 
enables it to communicate directly over the 
telecommunications network to communicate outcome 
transfer messages OTM from the LCC to the HTV and 
redemption request messages from the HTV to the LCC. 
In this connection,., the system could operate over 
any interactive communications network such as the 
Internet. Alternatively, the HTV may incorporate a 
cellular phone for the same purpose. This embodiment 
is still considered to be an off-line arrangement as 
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there is no need to have an on-line connection 
between the HTV and the LCC during play. 

In a further embodiment, the LCC and each HTV 
include transceivers for broadcasting and receiving 
5 RF communications of respective messages. Thus, the 
player need not travel to a lottery retailer to 
purchase outcomes or to redeem winnings. 

These and other features and advantages of the 
present invention will be better understood with 
10 specific reference to the detailed description which 
follows and the appended drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a schematic of the remote lottery 
system showing an LCC, ATs and HTV in a first 
15 embodiment ; 

FIG. 2 is a block diagram of the LCC; 
FIG, 3 is a diagram of an exemplary memory 
arrangement in the LCC; 

FIG. 4 is a block diagram of the components in 
20 an HTV; 

FIG. 5 is a block diagram of the controller in 
the HTV; 

FIG . 6 is a diagram of an exemplary memory 
arrangement in the HTV; 
25 FIGS. 7A and 7B are a flow chart of an 

exemplary outcome purchase; 

FIG. 8 is a flow chart of an exemplary 
redemption sequence; 

FIG, 9 is a schematic of a random prize 
30 datastream showing an example of purchased and 
standby outcomes; 

FIGS. IDA and lOB are a flow chart of an 
exemplary outcome purchase sequence with standby 
outcomes; 

FIG. 11 is a flow chart of an exemplary 
redemption sequence with standby outcomes; 
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FIG, 12 is a schematic of an alternative 
embodiment of the invention; and 

FIG. 13 is a schematic of another alternative 
embodiment ot the invention. 

DETAILED DESCR TPTION OF THE PREFERRED EMBODIMENTS 
With reference to the several views of the 
drawings, there is depicted a lottery system 
generally characterized in a first embodiment by the 
reference numeral 10, and principally comprised of a 
lottery authority 11 having . a LCC 12, a 
telecommunications network 14 which provides remote 
terminal access to the LCC 12, a plurality of agent 
terminals (AT) 16 associated with various lottery 
retailers 18, and a plurality of HTV units 2 0 which 
reveal purchased " tickets " outcomes . The term 
"lottery authority" is used in the general sense and 
is intended to include any wagering authority which 
sells no choice (e.g., scratch-off lottery tickets, 
bingo or a sweepstakes) or psuedo-choice (e.g., 
video poker) games or races of skill having a 
predetermined outcome if the player plays 
•correctly. The term "lottery retailers" includes 
any merchant where an AT 16 is located. As 
described in the foregoing, the term "ticket" as 
used herein means a single outcome. Thus, the 
player is really purchasing outcomes from the LCC 
which are transferred to the HTV 20 and revealed 
through games generated on the HTV 20. As will be 
explained in more detail below, the player need not 
go to a given lottery retailer to purchase outcomes. 
It is anticipated that, in alternative embodiments, 
the LCC 12 and AT 16 may be combined into a single 
unit or even into a system which enables outcomes to 
be purchased over the telephone or any interactive 
communications network. Alternatively, outcomes 
could be purchased through RF communications between 
a transceiver associated with the LCC 12 and a 
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transceiver associated with the HTV 20. These 
embodiments are described further below. 

FIG. 1 is a schematic block diagram depicting 
an overview of the system components in the first 
5 embodiment. The LCC 12, telecommunications network 
14 and ATs 16 are connected in similar fashion as 
those in the prior art used to dispense instant 
paper tickets. With respect to the present 
invention, each AT 16 may include a printer 22, bar 
10 code scanner or other scanning device 24, a 
communications interface 26 for physically coupling 
the HTV 20 to the AT 16 to electrically communicate 
signals with the HTV 20 through a compatible 
communications interface 92 in the HTV 20, and/or a 
15 read/write interface 27 for reading and writing data 
to data memory media such as a smart card 28. These 
are used to transfer outcomes to the HTV 20 through 
an outcome transfer message OTM and will be 
described in more detail below. The smart card 28 
may also be used to update game programs in the HTV 
20 to allow. for the generation of new games. In this 
regard, new games may be transferred to the HTV 20 
to inexpensively test them for market acceptance by 
players. The smart card 28 may also be used to 
transfer advertising information in connection with 
lotteries in general. 

FIG. 2 is a block diagram showing details of 
the LCC 12, which generally includes a CPU 30, 
memory 32, an I/O interface 34 for loading programs 
30 into memory 32, and a communications interface 35 
for communicating through the network 14 with the 
ATs 16. The LCC 12 may also communicate through a 
base station network 15 with a plurality of base 
stations having transceivers for broadcasting and 
35 receiving RF signals to communicate messages 
directly between the LCC 12 and the HTV 20 in an 
alternative embodiment described below and 



20 



25 



wo 97/02074 



PCT/US96/11156 



-17- 

illustrated in FIG. 13. The LCC has software or 
firmware (hereinafter referred to as "programs" and 
"data") which are used to implement various 
functions in tne system. FIG. 3 depicts an exemplary 
5 memory arrangement of programs and data stored in 
the LCC 12. Memory 32 includes an operating system 
program 33 which controls the LCC 12 in a 
conventional manner and need not be described in 
detail. The LCC 12 has a memory area 36 in memory 32 

10 for each HTV 20 in which specific information is 
stored to enable the LCC 12 to assign outcomes to 
that HTV 20 and to keep track of what has been 
assigned to that HTV 20 to provide for the 
redemption of winnings and to ensure that the HTV 20 

15 is a verified unit in connection with a given 
transaction. Data in memory 36 may be retrieved and 
updated as required in order to perform the desired 
functions. For purposes of convenience, the 
following description describes an HTV which is 

20 registered to a single player. However, it is 
anticipated that an HTV 20 may contain multiple 
accounts for different players where access to the 
HTV 20 is made available through different 
passwords. An HTV 20 must be initially 

25 registered with the lottery authority 11 prior to 
use. In this connection, identification information 
is initially stored in memory 32 of the LCC 12. The 
identification information includes a unit 
identifier or HTV ID ("I") stored in a field 37 and 

3 0 optionally a chaining variable ("C") stored in a 
field 38. I may constitute a 64-bit identifier 
which is unique to each HTV 20, Similarly, C may 
constitute a 64 -bit-representation of the history of 
outcomes which have been purchased and transferred 

35 to the particular HTV 20. Accordingly, C is updated 
every time purchased outcomes are assigned to the 
particular HTV 20 as a one-way function of the 
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out comes purchased. Thus, C is unique to each HTV 20 
•because it is a record of all transactions made with 
respect to that HTV 20. In one exemplary embodiment, 
C is used as a way to prevent fraud by generating 
an outcome purchase request message CPRM as a 
function of both I and C in the HTV 20 where OPRM is 
used to identify the particular HTV 20 during 
purchase and/or redemption transactions. In this 
regard, the current OPRM for that HTV 20 is stored 
in field 40 in the HTV memory area 36 in LCC memory 
32 to enable the LCC 12 to compare the generated 
OPRM with the one stored in memory (which is updated 
each time outcomes are sold to the HTV 20) from the 
last transaction to verify the identity of the HTV 
^5 20. C and I may also be used as encryption or 
authentication keys as described below. 

The LCC includes a program 42 for generating a 
random prize datastream ("RPD") 44 which is a pool 
containing a finite series of win/lose outcomes 
20 0^...0^ (e.g.,... win $2, win $2, lose, lose, 
win $10, lose, lose .... etc) , The aggregate of all 
winning outcomes in any RPD 44 is a predetermined 
percentage payout of the total revenues to be 
generated by the sale of all "tickets" represented 
25 by the outcomes in the RPD 44. When a purchase is 
made, the LCC 12 utilizes a "ticket" (outcome) 
purchase program 48 which randomly selects the next 
m outcomes from the RPD 44 (and possibly "standby 
outcomes" - x to allow for reinvestment of winnings, 
30 this will be described below) to be assigned to a 
particular HTV 20 . The outcome purchase program 48 
then directs the LCC 12 to generate the outcome 
transfer message OTM which is subsequently 
communicated to and read by the HTV 20 to enable the 
35 HTV 20 to reveal the outcomes. There are several 
ways in which this can be implemented. The outcome 
purchase program 4 8 will also direct the LCC 12 to 
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store the outcome transfer message OTM in field 50, 
a record of the outcomes m assigned in field 52, and 
the standby outcomes x assigned in field 54. 
Accompanying this data may be the price point for a 
given "ticket" (outcome) such as $.25, $1, $2, etc., 
in field 56, the net payoff in field 58, and the 
time/date in field 60. Thus, a record is generated 
in the LCC 12 for each transaction with a given HTV 
20. 

In one embodiment, each HTV 20 may be assigned 
a unique reference string ("HTVRS") which is stored 
in field 46. An identical HTVRS is stored in the 
particular HTV 20 as described below. The HTVRS is 
a random series of win/lose outcomes. When a 
15 purchase is made, the outcome purchase program 48 
directs the LCC 12 to find the same outcomes or a 
series of outcomes having the same net payoff in the 
HTVRS. These outcomes or the net payoff may be 
represented by one or more memory addresses in the 
HTVRS. The outcome purchase program directs the LCC 
12 to generate an outcome transfer message OTM which 
represents that address or addresses in the HTVRS. 
The HTV 20 can interpret OTM to find the same 
outcomes or a series of outcomes with the same net 
25 payoff in its very own HTVRS. This will be explained 
in more detail below. 

Another way in which the LCC 12 can assign 
outcomes is through the use of a one-way function 
which utilizes a seed value to generate a sequence 
of outcomes that are selected from the RPD 44. The 
HTV memory area 36 in the LCC memory 32 includes 
such a one-way function in field 62. An identical 
one-way function is stored in the HTV 20 as 
described below. The seed value for this one-way 
35 function becomes part of an outcome transfer message 
OTM. 
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Still another way the LCC can assign outcomes 

to the HTV 20 is by simply compressing the outcome 

sequence into a smaller code which is then 

decompressed in the HTV 20. Specifically, the LCC 12 

5 has a compression/decompression program 64 which 

takes a series of m outcomes 0,,..0. , selected 

3 ]+m' 

by the outcome purchase program 48 and compresses 

that sequence into a smaller variable which is part 

of an outcome transfer message OTM. As part of the 

10 compression process, the outcomes 0....0. mav 

] D+m 

be rearranged into a hierarchal order, i.e., number 
of losers, number of $1 winners, number of $2 
winners, etc) if desired. Compression is useful in 
embodiments where the outcome transfer message OTM 
15 is printed on a receipt or rendered in the form of a 
bar code, to allow for manual entry of the outcome 
transfer message OTM into the HTV 20 or scanning the 
OTM as described below. Compression is also useful 
in the telephone embodiment shown in FIG. 12 and 
20 described below where the player may communicate 
messages over the telephone in response to suitable 
prompts. In this regard, compression and 
decompression may be used in combination with any of 
the other methods of transferring outcomes, such as 
25 for example, where the HTVRS address is transferred. 

In still another embodiment, the outcome 
purchase program 48 calculates the expected net 
payoff of the m outcomes 0j.,.0j_^^ and generates 
an outcome transfer message OTM which represents 
30 that net payoff. In this case, the HTV would 
randomly generate games which yield outcomes having 
that net payoff. This method is not suitable for 
standby outcomes. 

In order to provide for added security in the 
35 system, the outcome transfer messages OTM may be 
encrypted using keys known only to the LCC 12 and 
the particular HTV 20 stored in field 66. An 
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authentication/encryption program 68 provides for 
the encryption and decryption of messages 
communicated from the LCC 12 and communicated to the 
LCC 12. Similarly, messages generated by the LCC 12 
5 may be made authenticatable by appending message 
authentication codes stored in field 70 such that 
only a particular HTV 20 using keys known only to 
the LCC 12 and that HTV 20 can use the message. As 
described above, the chaining variable C and the 
10 unit identifier I may be used as keys to perform 
encryption/decryption and authentication. 

Other programs resident in the LCC memory 32 
include an accounting program 72 which calculates 
the running cash balance for each HTV 2 0 and stores 
15 the same in an account 73 in field 74, The 
accounting program 72 is used to track the 
cumulative value of player winnings and losses after 
the player has cashed-out. The accounting program 72 
enables the LCC 12 to duplicate a player's credit 
20 balance at any point in the outcome sequence. 

The LCC memory 32 further contains an audit 
program 78 which stores a record of all transactions 
with a particular HTV 20 in field 76. 

The LCC memory 32 also includes a redemption 
25 program 79 which provides for verifying winnings to 
enable a player to cash-out. The redemption program 
78 is used to cash-out any winnings in a player's 
current credit balance. The redemption program 79 
directs the LCC 12 to read a redemption request 
30 message RRM provided from the HTV 20. The 
redemption program also determines the number of 
standby outcomes which were actually used by the 
player. All of . ..this will be explained in more 
detail below. 

In order to provide for tracking player 
history, data concerning a particular player may be 
stored in field 81 and bonus award data may be 
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stored in field 80. In this manner, the lottery 
authority 11 can provide players with loyalty 
rewards such as free outcomes for total "tickets" 
purchased or the like. 
5 Referring now to FIGS. 4 and 5, the HTV 20 in a 

preferred embodiment is a hand-held unit having a 
controller 82, a display 84, and player controls 86. 
Preferably the HTV 20 includes one or more of the 
following: a printer interface 88a for connecting 
10 the HTV 20 to an external printer, an internal 
printer 88b, a bar code scanner 90, a communications 
interface 92 compatible for connecting the HTV 20 to 
the communications interface 26 associated with an 
AT 16 to enable the HTV 20 to electrically 
15 communicate directly with the AT 16, a read/write 
interface 94 for reading data from and writing data 
to smart card 28, a modem 96 for connecting the HTV 
20 directly to a telecommunications network 14 
coupled to the LCC 12 in an alternative embodiment 
shown in FIG. 12 and described below, and an antenna 
115 coupled to a transceiver 113 for broadcasting 
and receiving messages to and from a base station 
600 associated with LCC 12 in another alternative 
embodiment shown in FIG. 13 and described below. 

The player controls 86 may be integrated into 
display 84 in a touch- screen arrangement of the type 
known in the art. The display 84 may also include 
the capability to render messages in a bar code 
readable format to enable them to be scanned by the 
bar code scanner 24 coupled to the AT 16. The player 
controls 86 allow the player to select various game, 
outcome transfer and redemption functions. The 
controller 82 includes a CPU 98, a clock 101 and 
.memory 100 comprised of ROM and RAM in a 
35 conventional arrangement. The controller 82 may be 
optionally housed in a tamper-evident enclosure to 
reveal to the lottery . authority 11 any suspected 
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tampering with the device. The CPU 98 communicates 
with the player controls 86 through a control 
interface 103, and with video generation hardware 
104 for driving the display 84, and sound generation 
hardware 106 coupled to a speaker 108 for 
communicating game sounds. A voice activated circuit 
110 of the type known in the art may be coupled to a 
microphone 112 to enable messages to be communicated 
to the CPU 98 by spoken commands. The CPU 98 
communicates with the printer interface 88a or the 
internal printer 88b, bar code scanner 90, interface 
92, read/write interface 94, and modem 96 through 
conventional I/O interfaces shown generally in the 
block diagram at 114, The CPU 98 may communicate 
with RF circuitry 113 coupled to an antenna 115 for 
communicating messages directly with the LCC 12 via 
the base station as shown in the alternative 
embodiment in FIG. 13. In another application, the 
HTV 20 may have a GPS receiver ill coupled to 
antenna 115 which communicates position information 
to the CPU 98. In this manner the HTV 20 can be 
prevented from operating unless it is located in a 
certain venue where gaming is permitted by a 
position enabling/disabling program in memory. 

The outcome transfer message OTM may be 
communicated to the HTV 20 using the following 
protocols. In a first embodiment, the AT 16 prints 
the outcome transfer message OTM on a receipt 30 and 
the agent provides the OTM to the player. The 
player simply enters the outcome transfer message 
OTM into the HTV 20 using the player controls 86. 
Alternatively, the AT 16 may print the outcome 
transfer message OTM in a bar code readable format 
to enable the bar code scanner 24 to simply scan the 
same. In either case, the receipt can be printed 
without ink using a carbonless two-part, form which 
the player tears off to prevent anyone else from 
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viewing the outcome transfer message OTM and then 
trying to input it to another HTV 20. Iil an 
alternative embodiment, the HTV 20 can connect to 
the AT 16 at interface 92 and the outcome transfer 
message OTM may be communicated directly to the HTV 
20 . In another embodiment, the OTM may be written 
to memory in the smart card 28 through the 
read/write interface 27 connected to the AT 16, The 
player then plugs the smart card 28 into the HTV 20 
and the OTM may be read by the HTV 20 from the smart 
card 28. In a further embodiment, the outcome 
transfer message OTM may spoken into the microphone 
112, either by the player, the agent or by an 
automated voice over the telephone in a telephone 
embodiment shovm in FIG. 12, and processed through 
the associated voice activated circuit 110. In 
another telephone embodiment, the HTV 20 may be 
connected to the telephone network 514 directly and 
the outcome transfer message OTM may be communicated 
to the HTV 20 through the modem 96, In the 
embodiment shown in FIG. 13, the outcome transfer 
message OTM may be communicated from the LCC 12 
through an RF transmission from either the AT 16 or 
the LCC 12. Redemption request messages RRM from the 
HTV 20 to enable players to cash-out winnings may be 
similarly communicated. 

Referring now to FIG. 6, there is depicted an 
exemplary memory arrangement 100 of programs and 
data in the HTV 20. Memory 100 includes an 
operating system generally indicated by the 
reference numeral 117 which controls the HTV 20 in a 
conventional manner. With respect to the present 
invention, the other programs and data in memory 
100 enable the HTV 20 to read outcome transfer 
messages OTM from the LCC 12 and to process these 
messages in order to generate games which yield the 
outcomes . The HTV memory 100 may also include a 
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. position enable/disable program lOl which disables 
the HTV 20 when position information from the GPS 
receiver ill indicates that the HTV 20 is located in 
a venae where gaming is impermissible. Information 
on gambling venues for use by the position 
enable/disable program may be stored in field 105. 
As described above with respect to the LCC memory 
32, each HTV stores a unit identifier I in field 116 
and optionally a chaining variable C in field 118. 
The HTV 20 may also store a serial number S in field 
120. A password (or multiple passwords for multiple 
players on a single HTV 20) is stored in field 122. 
When a player activates the HTV 20, a password 
security program 124 checks the player's password in 
15 a conventional manner before allowing the player to 
continue. The HTV memory 100 further includes an 
outcome purchase program 126 which directs the HTV 
20 to generate identification information to be 
transferred to the LCC 12, such as the outcome 
20 purchase request message OPRM, and to read the 
outcomes represented in the outcome transfer message 
OTM. When read by the HTV 20, the outcome transfer 
message OTM is stored in memory 100 in field 128. If 
the outcome transfer message OTM is compressed by 
25 the LCC 12, a compression/decompression program 130 
is called by the outcome purchase program 126 to 
decompress the outcome transfer message OTM into the 
outcome sequence. The m outcomes 0....0. are 
stored in field 132. if there are x"'*standby 
30 outcomes O^. . .0^^^ assigned, these are stored 
in field 134 . Accompanying this data may be the 
price point for each outcome in field 13 6, the net 
payof f , in field 138, and the time/date of entry in 
field 140. 

35 As described above with respect to the LCC 12, 

the outcome transfer message OTM may represent one 
or more memory addresses in a reference string 
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HTVRS. Accordingly, each HTV 20 may store an HTVRS 
in field 142, In such an embodiment, the outcome 
purchase program 126 directs the HTV 20 to find the 
sequence of outcomes or the net 

5 payoff on that sequence in the HTVRS. 

Alternatively, the outcome transfer message OTM 
may represent a seed value for a one-way function in 
field 144. Thus, the outcome purchase program 126 
directs the HTV 20 to generate the desired outcomes 
10 • • -^j+m ^^^^3 one-way function. The same 

one-way function is stored in the LCC memory 32. 

As described above , the outcome transfer 
messages OTM may be encrypted by the LCC 12 to 
prevent them from being used in another HTV 20. An 
15 authentication/encryption program 146 using 
algorithms of the type known in the art provides for 
the encryption and decryption of such messages 
communicated to and from the HTV 20. In this 
connection, the HTV 20 may store special keys for 
encrypting and decrypting such messages in field 
148. Similarly, messages from the LCC 12 having 
message authentication codes may be authenticated by 
the authentication/encryption program 14 6 using keys 
known only to the LCC 12 and the particular HTV 20 
25 stored in field 150. As described above with respect 
to the LCC memory 32, the chaining variable C which 
is unique to each HTV 20 may be used as a key to 
perform encryption/decryption and authentication. 

The HTV 20 includes a game generation program 
30 ("game program") 152 which provides for the 
generation of various games and win/lose scoring on 
the display 84, The game generation program may also 
include a tutorial for teaching players how to play 
the games and a help function for each game. These 
35 games can be generated with each having either a win 
.or lose outcome exactly corresponding to each 
outcome Oj...Oj^^ represented by the outcome 
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transfer message OTM. Thus, the game merely 
interprets or reveals the outcome. Alternatively, 
the games may be generated such that an m number of 
games have a net payoff equal to the net payoff in 
the series 0^ . . .0,^^. The latter is not suitable 
for embodiments where standby outcomes are assigned 
as described below, a single game may have multiple 
chances but only one outcome. The game program 152 
generates "no-choice" or non-skill games with a 
predetermined outcome such as, for example, the type 
commonly associated with pull -tab type instant 
lottery tickets, a sweepstakes, or bingo; or 
psuedo-choice games with a predetermined outcome 
such as video poker. In the case of the latter, the 
outcome for a particular poker game is predetermined 
with a maximum payoff which is recovered if the 
player plays every hand correctly. If the player 
plays incorrectly, the payout is less than the 
maximum represented by the outcome for a particular 
game. In addition, the game program 152 may generate 
games which are races of skill such as crossword 
puzzles or word descrambler games which must be 
completed within a specified period of time. If the 
player completes the game in the time allotted, the 
player is paid the predetermined payoff on the 
outcome selected for that game. If not, a win is not 
credited to the HTV account 155 described below. 
Programs for generating such games are known in art. 
The game program 152 can be designed to require a 
game identifier such that the lottery authority ii 
selects which games are to be played in connection 
with any outcomes that are sold. In this regard, 
the outcome transfer message OTM may include an 
instruction for the game program 152 to generate a 
35 specific game for those outcomes. in order to 
provide for updating games in the HTV 20, new game 
programs could be loaded into memory 100 in a 
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plugging the HTV 20 into the AT 16 as described 
above and then uploading the appropriate software 
instructions , 

5 The HTV memory 100 also includes an accounting 

program 154 which directs the HTV 20 to calculate 
the running cash balance which is stored in an 
account 155 in field 156. If there are several 
players assigned to a given HTV 20, there may be 

10 individual accounts for each player. 

The HTV memory further includes a redemption 
program 158 which is used to cash-out the player's 
current credit balance in the player's account 155. 
The redemption program 158 enables the player to 

15 select a cash-out function on the HTV 20. The 
redemption program 158 then directs the HTV 20 to 
generate a redemption request message RRM which is 
communicated to the LCC 12 using methods similar to 
the way in which outcome transfer message OTM was 

20 communicated to the HTV 20, but in reverse. 
Redemption request messages RRM are used by the 
redemption program 79 in the LCC 12 to verify 
cash-out requests by comparing HTV identification 
data and outcome data (net winnings, the number of 

25 games played) for a given HTV 20. The redemption 
request message RRM may be generated on the display 
84 of the HTV 20 and orally provided to the agent at 
a lottery retailer 18 for manual entry into the AT 
16. The redemption request message RRM can be 

30 printed onto a receipt 30, either by an internal or 
external printer 88b associated with the HTV 20, or 
by a printer 22 at the lottery retailer via the 
printer interface 88a, which receipt 3 0 is then 
provided to the agent. In this connection, the 

35 redemption request message RRM may be rendered on 
the display 84 or on the receipt 3 0 in a bar code 
readable format and scanned by the bar code scanner 



wo 97/02074 



-29- 



PCT/US96/11156 



24 at the AT 16 . In another embodiment, the 
redemption request message RRM may be written to the 
smart card 28 and then read therefrom by the AT 16. 
In yet another embodiment, the redemption request 

5 message RRM can be communicated to the LCC 12 over 
the telephone network 14 via the modem 96. In still 
another embodiment, the redemption request message 
RRM may be communicated from the HTV 20 to the LCC 
12 through an RF transmission to either the AT 16 

■0 or the LCC 12. The redemption request message RRM 
may be encrypted by the HTV 20 using the 
authentication/encryption program 146 in memory 100 
for subsequent decryption by the LCC 12 using the 
authentication/encryption program 68 in memory 32. 

5 The redemption request message RRM can be encrypted 
using encryption keys known only to the LCC 12 and 
the specific HTV 20. These may include the unit 
identifier I and the chaining variable C. 

The HTV memory 100 also includes an audit 
program 160 which stores a record of all activity 
performed on the HTV 20 in field 161 to assist in 
protecting data integrity and to verify that the 
various programs in memory 100 have not been 
tampered with. The audit program 160 further 
provides a record of player activity for the player 
and the lottery authority 11 in the event of any 
dispute • 

Referring now to FIGS. 7A and 7B, there is 
shown a flowchart of an exemplary outcome purchase 
of m "tickets" (outcomes) from the LCC 12 through an 
AT 16 at a lottery retailer 11. For convenience, 
the following assumes all outcomes are purchased at 
a single price point. However, the outcomes 
purchased from the,, RPD 44 may represent different 
price points and may be purchased separately by 
obtaining an outcome transfer message for each price 
point, or together by generating an outcome transfer 
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message OTM which represents outcomes having 
different price points. To begin the purchase 
sequence, the player first activates the HTV 20 and 
enters his or her password which is checked by the 
5 password security program 124. The player then 
selects the purchase "ticket" function at step 300. 
The outcome purchase program 12 6 directs the HTV 20 
to generate an outcome purchase request message OPRM 
as a one-way function of I and C at step 302. The 
10 player provides the OPRM to the agent at the lottery 
retailer 11 at step 304. The agent then enters the 
OPRM into the AT 16 which transmits the OPRM to the 
LCC at step 306. The serial number OPRM could also 
have been provided to the agent by any of the above 
15 described methods of communicating an outcome 
transfer message OTM or a redemption request message 
RRM as described above. The LCC 12 runs its outcome 
purchase program 48 at step 308 which extracts I and 
C from S for that HTV 20. At step 310, the LCC 
20 compares I and C with the values for I and C stored 
in fields 37 and 38, respectively, in the HTV memory 
area 36 for that HTV 20. As described above, I and C 
are initially stored in the LCC 12 when the 
particular HTV is registered with the lottery 
25 authority 11. C for a given HTV 20 is updated using 
a one-way function every time outcomes are 
transferred to that HTV 20. If I and C match, then 
the LCC 12 sends a ready code to the AT 16 at step 
312. If not, then the LCC 12 denies the outcome 
3 0 purchase request because the HTV 20 is not 
registered or has been altered in some way at step 
314, If the HTV identification is valid, the player 
then provides the agent with the number of outcomes 
m to be purchased for a given price point at step 
i5 316. The agent enters m and the price point into the 
AT 16 at step 318. The AT 16 transmits m and the 
price point to the LCC at step 320. The outcome 
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purchase program 48 in LCC memory 32 then randomly 
selects the next m unsold outcomes O. 0 
for that price point from the RPD 44 at step 322. It 
also directs the LCC 12 to store the outcomes 
'^j'^'^j+m field 52, the price point in field 

56, the net-payoff in field 58 and the time/date in 
field 60, The LCC 12 then generates an outcome 
transfer message OTM at step 324 using any one of 
the methods described in the .foregoing. The LCC 12 
can also store the outcome transfer message OTM for 
the given purchase in memory in field 50. As 
discussed in the foregoing, the LCC 12 can use the 
authentication/encryption program 68 to encrypt the 
outcome transfer message OTM, in this example first 
15 using I as an encryption key and then using C as an 
encryption key at step 326 (the OTM need not be 
encrypted, it could be made authenticatable by 
appending message authentication codes which are 
authenticated in the HTV 20 by keys known only to 
the LCC 12 and the HTV 20) . It then updates C as a 
one-way function of the outcome transfer message - 
C=f(OTM), and stores the new value for C in field 38 
at step 328. The LCC 12 then transmits the outcome 
transfer message OTM to the AT 16 at step 330. The 
25 AT prints a receipt 3 0 containing the OTM, the date, 
time, price point and m at step 332. The agent then 
provides the receipt 30 containing the outcome 
transfer message OTM to the player, and the player 
pays the agent at step 334. At this time, an outcome 
30 purchase confirmation message is communicated from 
the AT 16 to the LCC 12 at step 336 which indicates 
that the player has "irrevocably" purchased the 
outcomes represented by the outcome transfer message 
OTM. The player then enters the outcome transfer 
35 message OTM into the HTV 20 at step 338. The HTV 20 
runs the authentication/encryption program 146 to 
decrypt the outcome transfer message OTM first using 
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C as the key and again using I as the key at step 
340. The outcome transfer message OTM is then stored 
in field 128 in HTV memory 100 at step 342. If the 
outcomes are simply compressed into a sequence 
5 Oj..,Oj^j^ (FIG. 9), the decompression/ 

compression program 130 will decompress the sequence 
and store the same in field 132. The outcome 
purchase program 13 0 may also store the price point 
in field 136, and net payoff in field 138. If the 
10 outcome transfer message OTM represents an address 
in the HTVRS, the outcome purchase program 13 0 will 
search the HTVRS stored in field 142 for that 
address or an address where a series of outcomes 

reside with the same net payoff as 0 0. if 

-Li the outcome transfer message OTM represents a seed 
value for a one-way function stored in field 144, 
the outcome purchase program 130 will use the seed 
value to generate the same series of outcomes 
°j'*'°j+m • Alternatively, the outcome transfer 
message OTM may simply represent the net-payoff on a 
number of m outcomes 0....0.^^, in which case 
the game program 152 generates a number of games 
with the same net payoff. Once the outcome message 
OTM has been stored in step 342, the outcome 
purchase program 126 updates C as a one-way function 
of OTM and stores the new value for C in field 118 
at step 344. Thus, both the HTV 20 and the LCC 12 
have new values for C stored in memory. The player 
then plays games on the HTV 20 generated by the game 

30 program 152 which yield the outcomes O 0. 

or the net payoff on those outcomes at step 346"^ 
The player's account balance is updated by the 
accounting program 154 as each outcome is revealed 
and stored in account 155 in field 156 at step 348. 

FIG- 8 is an exemplary cash-out sequence in the 
embodiment described above. Essentially, the HTV 20 
identifies itself to the LCC 12 and the LCC 12 
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authorizes a payoff on the outcome sequence 
Oj...Oj^^ sold to that HTV 20. To begin the 
redemption sequence, the player first activates the 
HTV 20 and enters his or her password which is 

5 checked by the password security program 124 as 
described above. The player then chooses the 
cash-out function at step 350. The redemption 
program 158 in HTV memory 100 generates the 
redemption request message RRM, in this example, as 

10 a function of I and C at step 352. Thus, the 
redemption request message RRM is similar to the 
outcome purchase request message OPRM described in 
the outcome purchase sequence of FIGS. 7A and 7B. 
The RRM may also include the updated cash balance in 

15 account 155 which represents the payoff on the 
outcomes which were revealed. The value for C was 
updated as a one-way function of the outcome 
transfer message OTM at step 344 above. The value 
for C was also updated in the LCC memory 32 at step 

20 328 above. The player provides the redemption 
request message RRM to the agent at step 354. The 
agent then activates a redemption function on the AT 
16 at step 356. The agent enters the redemption 
request message RRM into the AT 16 which transmits 

25 the RRM to the LCC 12 at step 358, The LCC 12 then 
runs the redemption program 79 which verifies the 
redemption request message RRM by extracting I and C 
and comparing the values for I and C with the values 
stored in memory 32 in fields 37 and 38, 

30 respectively, at step 360. If I and C do not match 
the expected values at step 362, the LCC 12 denies 
the cash-out request at step 364. If I and C match 
the expected values at step 362, then at step 364 
the LCC 12 checks the cash balance embodied in the 
35 redemption request message RRM against the amount it 
calculated (the payoff stored in field 58 for that 
outcome sequence) as a result of the sale of the 
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outcomes to the HTV 20 and stored previously in the 
HTV account 73 in field 74. The LCC 12 then sends a 
validation message to the AT 16 at step 368 and the 
amount is debited in account 73. The player may opt 
5 to purchase more outcomes with the present cash 
balance in account 73 at step 370, in which case the 
outcome purchase sequence shown in FIG. 7 may be 
repeated. Alternatively, the player is paid by the 
agent at step 372. 

As described briefly above, an outcome purchase 

request for m outcomes 0....0, may be 

3 ] +m ^ ^ 
accompanied by x standby outcomes O . . .0 . The 

® s+x 

standby outcomes are supplied in a number sufficient 
to exhaust all winnings, or so as to generate a 

15 large win at some point in the sequence above a 
predetermined value where the outcome purchase 
program 126 in the HTV 20 will direct the HTV 20 to 
stop generating games and provide a cash-out 
instruction on the display 84. Referring now to 

20 FIG, 9, there is shown a portion of an RPD 44 with 

five (5) purchased outcomes 0...-0. which 

3 3+m 

have a net-payoff of $16. In this example, the 
outcome purchase program 48 in the LCC 12 has 
selected twenty four (24) standby outcomes 

25 Og...Og^^ in two groups as shown. The standby 
outcomes can be selected from anywhere in the RPD 44 
but the groups are played in order. The relative 
positions between the purchased outcomes m and the 
standby outcomes x shown in the RPD 44 are merely 

30 exemplary. For the purpose of this example, all 
outcomes are purchased for $1. The player wins $16 
on the purchased outcomes Oj...O.^^. If the 
player spends that $16 on the first group of sixteen 
(16) standby outcomes and those outcomes yield a 

35 net payoff of $8, the next group may constitute 
eight (8) outcomes which yield a net payoff of zero 
(0) in the first example (full exhaustion of 
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winnings) or some large prize (e.g., $500) 
represented by the fourth outcome in the order shown 
in the second example for the second group. 
Referring to the second example, if the outcome 
5 aequerrce in the second group is played in order, and 
the sequence of outcomes is lose, win $2, win $1, 
win $500, the player retains $4 in winnings after 
the first standby group is played and $2+$l+$500 in 
the second group for a net win of $507. The game 
10 program 152 in the HTV 20 will direct the HTV 20 to 
generate a cash-out message when such a large 
outcome is revealed. If there are any remaining 
standby outcomes, in this example four losers, these 
will be voided in the HTV 20 by the redemption 

15 program 158, Similarly, those four standby outcomes 
will be voided in the LCC 12 when the LCC 12 is 
provided with a redemption request message RRM which 
represents all outcomes transferred to that HTV 20, 
including the m purchased outcomes , and the x 
standby outcomes. Since the player may choose to 
cash-out at some time during the sequence before all 
standby outcomes are revealed, the redemption 
request message RRM generated by the HTV 20 
represents which standby outcomes were revealed by 

25 the HTV 20 and enables the LCC 12 to compute the 
proper payoff and to void any unused standby 
outcomes in the LCC 12. 

Referring now to FIGS. lOA and lOB, there is 
shown an exemplary flowchart of an outcome purchase 

30 sequence including m purchased outcomes 

^H-'-O-j^^ and X standby outcomes O . . ,0 
D D+fTi s s+x 

The protocol in the example is similar to what 
happens in FIG. 7, so redundant steps will not be 
repeated. At step 400, the outcome purchase program 
'5 4 8 in LCC memory randomly selects m purchased 
outcomes ^j'-'^j+m ^ standby outcomes 

0«---Oc,u.^ ^^^^ 44, The LCC 12 then 
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generates an outcome transfer message OTM 
representing the m outcomes and x standby outcomes 
at step 402, The outcome transfer message may 
consist of a compressed sequence, address for 
outcomes in the HTVRS or a seed value for a one-way 
function as described above. The LCC 12 can update C 
as a function of the outcome transfer message OTM 
and store the same in memory as described above at 
step 404. Once the outcome transfer message OTM has 
been read and authenticated (if authenticatable) or 
decrypted (if encrypted) , it is stored in memory 100 
in field 128 in the HTV 20 at step 406. In this 
regard, the m outcomes ^^...Oj^^ may be stored 
in field 132 and the standby outcomes 
^5 ^s'"^s+x "^^y ^® stored in field 134 of the 
HTV memory 100. The same data has been stored in the 
LCC memory 32. At step 408, the HTV updates C as a 
one-way function of OTM. The HTV 20 then generates 
games which yield the m outcomes 0»...0, or 
the net payoff on those outcomes at step 410. The 
HTV 20 utilizes the accounting program to update the 
cash-balance in account 155 at step 412. Up to this 
point, the protocol is generally the same as shown 
in FIG. 7. At step 414, the outcome purchase program 
25 126 directs the HTV 20 to display the option to 
reinvest the cash-balance (winnings) in account 155. 
If the player wishes to cash-out, the cash-out 
sequence in FIG. 7 may be followed. If the player 
wants to reinvest, the game program 152 will 
generate a game which yields a standby outcome in 

^s*"*^s+x ®^®P '^^^ accounting program 

154 in the HTV 20 updates account 155 with a new 
cash-balance and displays the updated balance to the 
winner on the display 84, depending upon whether the 
35 standby outcome was a winner or loser at step 418. 
The outcome purchase program 126 then voids the last 
standby outcome revealed at step 42 0 and updates the 
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Status (to "revealed") of that outcome in the 
sequence of standby outcomes stored in field 54. If 
the last standby outcome revealed generates a large 
prize over some predetermined threshold at step 422, 
the outcome purchase program 4 8 directs the HTV 20 
to display a message to the player that he or she 
must cash-out at step 424. The player goes through 
the redemption sequence in FIG , 11 . If not , the 
outcome purchase program 48 checks to determine 
whether there are any unused standby outcomes 
remaining in field 54 at step 426. If not, the 
player has exhausted the cash-balance in account 155 
and the HTV 20 generates a zero cash-balance on the 
display 84 at step 428. If standby outcomes remain, 
the player chooses whether to continue to reinvest 
at step 430. If the player selects reinvestment, the 
HTV 20 will generate another game which yields the 
next standby outcome at step 416 . If the player 
elects to cash-out, the HTV 20 indicates the 
cash-balance in account 155 at step 432 and the 
player goes through the redemption sequence in FIG, 
11. 

Referring now to FIG. 11, there is shown an 
exemplary cash-out sequence when there are standby 
outcomes. To begin the redemption sequence, the 
player first activates the HTV 20 and enters his or 
her password which is checked by the password 
security program 124 as described above. The player 
initiates the cash-out function at step 500. The 
redemption program 158 in HTV memory 100 generates a 
status record of the standby outcomes and the 
accompanying cash balance in account 155 RSBY at 
step .502 and a redemption request message RRM as a 
function of I and C which appends RSBY at step 504. 
The redemption program 79 also voids any unused 
standby outcomes stored in field 54. The redemption 
request message RRM may be compressed by the 
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decompression/compression program 146 in HTV memory 
100 into a smaller message since the record of 
standby outcomes may be lengthy if the RRM is to be 
displayed on the HTV display 84 or printed out on a 
5 receipt 3 0 (either in alphanumeric form or in a bar 
code readable format) . This example describes an 
embodiment where the player provides the redemption 
request message RRM to an agent at the lottery 
• retailer 18 at step 506. As described above, the 
10 redemption request message may be communicated to 
the AT 16 through other methods. The agent selects 
a redemption function on the AT 16 at step 508. The 
agent then enters the redemption request message RRM 
into the AT 16 and the AT 16 communicates the 
15 redemption request message RRM to the LCC 12 at step 
510. The LCC then runs the redemption program 79 to 
verify the redemption request message RRM by 
extracting RSBY, I and C and comparing the values 
for I and C with those stored in memory 100 in 
20 fields 37 and 38, respectively, at step 512. If I 
and C do not match the expected values at step 514, 
the LCC 12 denies the cash-out request at step 516. 
If I and C match the expected values at step 514, 
then the LCC 12 uses the accounting program 154 to 
25 calculate the payoff on the standby outcomes 
represented in RSBY and credits the HTV account 155 
in field 156. The LCC 12 then voids any unused 
standby outcomes represented in the RSBY at step 
520. The LCC 12 then sends a validation message to 
30 the AT 16 at step 522. 

Referring now to FIG. 12, an LCC 12 is coupled 
to a telecommunications network 14' having 
interactive voice capability and is accessible by 
dialing a 900 number or the like to enable the 
35 outcome purchase and redemption to be effectuated 
over the telephone 13, Alternatively, the 
telecommunications network 14' may be any 
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interactive communications network, including the 
Internet. The protocol is similar to that described 
above with regard to purchase and redemption at an 
AT 16, except here the player simply keys the 
5 information into the telephone 13 in response to 
prompts from the system. Thus, the player first 
communicates the HTV identification information in 
the form of an outcome purchase request message OPRM 
to the LCC 12. If HTV identification/registration is 

10 confirmed, the LCC 12 then provides a "ready" 
indication to the player with instructions to select 
the number of outcomes to be purchased for each 
price point. The LCC 12 then generates an outcome 
transfer message OTM as described above which the 

15 player manually keys into the HTV 20. The system 
operates Similarly to redeem winnings. The HTV 20 
generates a redemption request message RRjyi, and the 
player keys the redemption request message into the 
telephone. The redemption request message RRM is 

20 communicated to the LCC 12, which verifies the 
identity of. the HTV 20 and the expected payoff. A 
credit is then made to an account for the HTV/player 
in the LCC 12. In a modification of this embodiment, 
the HTV 20 contains a modem 96 which enables it to 

25 communicate directly over the telecommunications 
network 14' to communicate outcome transfer messages 
OTM from the LCC 12 to the HTV 20 and redemption 
request messages RRM from the HTV 2 0 to the LCC 12. 
Alternatively, the HTV 20 may incorporate a cellular 

30 phone (not shown) for the same purpose. This 
embodiment is still considered to be an off-line 
arrangement as there is no need to have an on-line 
connection between the HTV and the LCC during play. 

In a further embodiment shown in FIG. 13, the 

35 LCC 12 communicates through a base station network 
15 with a plurality of base stations 600 for 
broadcasting and receiving RF messages. The HTV 20 



wo 97/02074 



PCT/US96/ni56 



-40- 

also includes a transceiver 113 for broadcasting 
and receiving RF communications such that all 
purchase and redemption functions may be implemented 
without the need for the player to travel to a 
lottery retailer. The protocol is similar to that 
described above with respect to the other 
embodiments. 
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1. A remote lottery system which enables a player to 
purchase outcomes from a randomized prize datastream 
in a central computer and view the outcomes on a 
remotely disposed gaming computer which does not 
require an on-line connection to the central 
computer, comprising: 

a central computer including a memory and means 
in memory for storing a randomized prize datastream 
comprised of a finite series of random win/lose 
outcomes, means in memory for storing a record of 
identification data for a plurality of off-line 
gaming computers, means in memory for directing said 
central computer to randomly assign outcomes from 
said randomized prize datastream to said gaming 
computers responsive to outcome purchase requests by 
players for a requested number of outcomes in each 
purchase, means in memory for storing a record 
representative of said purchased outcomes with said 
identification data for each of said gaming computers 
to enable subsequent redemption of outcome wins, and 
means in memory for directing said central computer 
to generate outcome transfer messages in connection 
with said outcome purchase requests to be 
communicated to said gaming computers to enable said 
gaming computers to reveal said purchased outcomes 
selected from said randomized prize datastream; 

each of said gaming computers including player 
controls, a display and a memory, said gaming 
computer further comprising means in memory for 
directing said gaming computer to generate games, 
means in memory for reading said outcome transfer 
message and to . - direct said gaming computer to 
generate games which yield at least one of the group 
consisting of said purchased outcomes and an 
aggregate net payoff of said purchased outcomes, and 
means in memory for directing said gaming computer to 
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generate a redemption message to be communicated to 
said central computer to cash-out, whereby, said 
central computer processes said redemption request 
message to check said record in memory of said 
outcomes assigned to said gaming computer in 
connection with said outcome purchase request to 
enable any payoff on said assigned outcomes to be 
made to the player, 

2. The remote lottery system recited in Claim 1, 
further comprising a plurality of agent terminals 
networked to said central computer, said agent 
terminals for enabling a player to purchase outcomes 
from said randomized prize datastream in said central 
computer and for enabling the player to redeem 

15 outcome wins, where at least one of said agent 
terminals is operably connected to a printer for 
printing a receipt with said outcome transfer message. 

3. The remote lottery system recited in Claim 2, 
wherein said outcome transfer message is printed on 
said receipt in a bar code readable format, and said 
gaming computer further comprises a bar code scanner 
for scanning said outcome transfer message. 

4. The remote lottery system recited in Claim l, 
further comprising a plurality of agent terminals 

25 networked to said central computer, said agent 
terminals for enabling a player to purchase outcomes 
from said randomized prize datastream in said central 
computer and for enabling the player to redeem 
outcome wins, where at least one of said agent 
30 terminals comprises an interface for reading and 
writing data to data storage media and said gaming 
computer comprises an interface for reading and 
writing data to said data memory media to communicate 
said outcome transfer message from said agent 
terminal to said gaming computer via said data memory 
media . 
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5, The remote lottery system recited in Claim 1, 
further comprising a plurality of agent terminals 
networked to said central computer, said agent 
terminals for enabling a player to purchase outcomes 
from said randomized prize datastream in said central 
computer and for enabling the player to redeem 
outcome wins, wherein at least one of said agent 
terminals is adapted to physically connect said 
gaming computer thereto, whereby said outcome 
transfer message may be communicated to said gaming 
computer from said agent terminal and said 
identification data and said redemption message may 
be communicated from said gaming computer to said 
agent terminal . 

6, The remote lottery system recited in Claim 1, 
wherein said central computer communicates through a 
telephone network having interactive voice capability 
to enable a player to purchase said outcomes over 
said telephone network by manually keying in gaming 
computer identification and outcome purchase data 
through a telephone to communicate said 
identification and outcome purchase data to said 
central computer, said central computer verifying 
said gaming computer by comparing said identification 
data with said identification data stored in memory, 
and upon said verification communicating said 
outcome transfer message in the form of an audible 
code to enable the player to manually key said 
outcome transfer message into said gaming computer 
through said player controls. 

7, The remote lottery system recited in Claim 1, 
wherein said central computer communicates through a 
telephone network and said gaming computer includes a 
modem to enable said gaming computer to communicate 
with said central computer over said telephone 
network to directly communicate said outcome transfer 
message to said gaming computer. 
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8. The remote lottery system recited in Claim 1, 
wherein said central computer is operably associated 
with RF transmitting means for receiving outcome 
purchase request messages and receiving means for 
5 broadcasting said outcome transfer messages, and said 
gaming computers are operably associated with RF 
transmitting means for broadcasting said outcome 
purchase request messages and receiving means for 
receiving said outcome transfer messages. 
10 9. The remote lottery system recited in Claim 1, 
wherein at least one of said messages is encrypted by 
said central computer and decrypted by said gaming 
computer, 

10. The remote lottery system recited in Claim 1, 
15 wherein at least one of said messages is encrypted 

by said gaming computer and decrypted by said central 
computer. 

11. The remote lottery system recited in Claim 1, 
wherein at least one of said messages is 

20 authenticatable and said gaming computer further 
comprises means in memory for authenticating said 
messages, 

12. The remote lottery system recited in Claim 1, 
wherein at least one of said messages is 

25 authenticatable and said central computer further 
comprises means in memory for authenticating said 
messages . 

13. The remote lottery system recited in Claim 1, 
wherein said central computer includes means in 

30 memory for storing outcome reference strings for each 
gaming computer with said respective identification 
data, each of said outcome reference strings being 
comprised of a plurality of random reference 
outcomes, each of said reference outcomes having an 

35 address in memory, and said gaming computers each 
have a corresponding outcome reference string stored 
in memory, whereby said central computer assigns 
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outcomes from said randomized prize datastream by 
retrieving at least one address of a series of 
reference outcomes in said reference string from 
memory and generating said outcome transfer message 
which represents said at least one address to enable 
said gaming computer to reveal reference outcomes in 
said reference string in said gaming computer at said 
at least one address . 

14. The remote lottery system recited in Claim 2, 
wherein said central computer further includes means 
in memory for compressing data representing said 
outcomes in said randomized prize datastream into 
said outcome transfer message and said gaming 
computer includes means for decompressing said data 

15 to enable a player to manually enter said outcome 
transfer message printed on said receipt into said 
gaming computer through said player controls, 

15. The remote lottery system recited in Claim 1, 
wherein said central computer further includes means 
in memory for generating a seed value for an 
algorithm stored in memory in said gaming computer, 
said gaming computer further comprising means in 
memory responsive to said seed value to enable said 
gaming computer to gene?rate said purchased outcomes 

25 selected from said randomized prize datastream by 
said central computer, where said outcome transfer 
message includes said seed value. 

16. The remote lottery system recited in Claim 1, 
wherein said central computer assigns a number of 

30 standby outcomes from said randomized prize 
datastream greater than said requested number of 
outcomes for said outcome purchase and said gaming 
computer has means in memory for reinvesting winnings 
on said requested number of outcomes to enable the 

35 purchase of said standby outcomes on said gaming 
computer. 
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17, A remote lottery system which enables a player to 
purchase outcomes from a randomized prize datastream 
in a central computer and view the outcomes on a 
remotely disposed portable gaming computer which does 
5 not require an on-line connection to the central 
computer, comprising: 

a central computer including a memory and means 
in memory for storing a randomized prize datastream 
comprised of a finite series of random win/lose 
10 outcomes, means in memory for storing a record of 
identification data for a plurality of off-line 
portable gaming computers, means in memory for 
directing said central computer to randomly assign 
outcomes from said randomized prize datastream to 
said gaming computers responsive to outcome purchase 
requests by players for a requested number of 
outcomes in each purchase, means in memory for 
storing a record representative of said purchased 
outcomes with said identification data for each of 
said gaming computers to enable subsequent redemption 
of outcome wins, and means in memory for directing 
said central computer to generate outcome transfer 
messages in connection with said outcome purchase 
requests to be communicated to said gaming computers 
25 to enable said gaming computers to reveal said 
purchased outcomes selected from said randomized 
prize datastream; 

each of said portable gaming computers including 
player controls, a display and a memory, said gaming 
3 0 computer further comprising means in memory for 
directing said gaming computer to generate games, 
means in memory for reading said outcome transfer 
message and to direct said gaming computer to 
generate games which yield at least one of the group 
35 consisting of said purchased outcomes and an 
aggregate net payoff of said purchased outcomes, and 
means in memory for directing said gaming computer to 
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generate a redemption message to be communicated to 
said central computer to cash-out; 

a plurality of agent terminals networked to said 
central computer, each of said agent terminals for 
5 enabling a player to purchase a requested number of 
said outcomes from said randomized prize datastream 
in said central computer at said agent terminal by 
entering said outcome purchase request into said 
agent terminal and communicating said outcome 

10 purchase request from said agent terminal to said 
central computer, and for enabling the player to 
redeem outcome wins by communicating said redemption 
request message generated by said gaming computer 
from said agent terminal to said central computer, 

^5 whereby, said central computer processes said 

redemption request message to check said record in 
memory of said outcomes assigned to said gaming 
computer in connection with said outcome purchase 
request to enable a payoff on said assigned outcomes 

20 to be made to the player. 
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D1 teaches an off-line remote lottery system. 

D2 teaches a method and apparatus for detemiining a caller's odds for winning a lottery based 
on caller history, 

D3 teaches networked gaming devices that end a bonus and concurrently initiate another 
bonus. 

The examiner has identified the following defects in the application: 
Ovetview 

Claims 1 to 28 fall to comply with section 2 of the Patent Act 

Uos\ critical is the subject matter of this application, which is introduced as a system and 
method for recognizing a wagerer. More specifically, the application proposes a scheme for 
recognizing a wagerer by detennining If the wagerer is to be recognized using some 
circumstantial criteria. Although the application recommends the use of software and computer 
hardware, no new technology, hardware, software, or data structures are disclosed. 

Using a known system to recognize a wagerer, however does not manufacture a vendible and 
tangible product, operate an inventive machine or operate a known machine for an Inventive 
new use. Therefore, using known equipment and technology to recognize a wagerer does not 
produce an essentially economic result relating to trade, commerce or industry, fn the meaning 
given those words by the courts and as explained in section 12,02-01a of the Manual of Patent 
Office Practice (MPOP). A method that does not produce an essentially economic result in 
relation to trade, commerce or industry Is not an ''art" under section 2 of the Patent Act. A 
system is included to embody and cany out the method for recognizing a wagerer, but does not 
add any additional patentable subject matter In Itself that could be considered outside the scope 
of what is already known in the field of hardware technology; for example, computers are 
expected to, among other things, provide and receive data. A discovery of a method that does 
not produce an essentially economic result in relation to trade, commerce, or industry cannot be 
made patentable merely by having It canied out by known technology and the fact that a 
computer is or should be used to implement that discovery does not change the nature of that 
discovery. 

Therefore, the discovery pertaining to recognizing a wagerer as disclosed by this application as 
a whole is not patentable under section 2 of the Patent Act. 
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In spite of the above-mentioned violation In the application which Is seen to be sufficient to 
render the application unpatentable, for the sake of completeness, the Office will also show 
other grounds on which this application is also being refused for a patent. 

Claimed subject matter 

Claim 1 describes a method for recognizing a wagerer. Using a known system to recognize a 
wagerer, however, does not manufacture a vendible and tangible product, operate an Inventive 
machine or operate a known machine for an Inventive new use. Therefore, using known 
equipment and technology to recognize a wagerer In accordance with a particular computer- 
Implemented scheme does not produce an essentially economic result relating to trade, 
commerce or industry, in the meaning given those words by the courts and as explained In 
section 12.02,01a of the MPOP. A method that does not produce an essentially economic 
result in relation to trade, commerce or industry Is not an "art" under section 2 of the Patent Act. 

Claims 2 to 14 are each dependent on claim 1 and fail to overcome the objections made for that 
claim. 

Therefore, the method of claims 1 to 14 fail to fall Into any of the categories of art, process or 
manufacture under section 2 of the Patent Act. 



Obviousness 

Claims 1 to 28 do not comply with section 28.3 of the Patent Act. The subject matter of these 
claims would have been obvious on the claim date to a person skilled in the art or science to 
which it pertains having regard to D1 in view of D2. 

Regarding claim 1, D1 and D2 describe a method for recognizing a wagerer (D1 : page 5, lines 
29 to 31; page 15, line 5 to page 16, line 26; page 22, lines 25 to 32; and page 26, lines 29 to 
34), comprising; selecting a wagerer {D2: column 3, lines 23 to 26; and column 4, lines 7 to 27); 
determining if the wagerer is to be recognized (D2: column 3, lines 36 to 54; and column 4, lines 
34 to 49); and providing an incentive to the wagerer if the wagerer Is determined to be 
recognized {D2: column 4, lines 50 to 60). 
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Claim 15 contains subject matter which does not differentiate itself patentably from what Is 
outlined in claim 1. and therefore, would also have been obvious on the claim date In view of the 
prior art. 

Claims 2 to 14 and 16 lo 28 are dependent on one of the above claims and would also have 
been obvious on the claim date to a person skilled in the art or science* 

Therefore, claims 1 to 28 do not comply with section 28.3 of the Patent Act The subject matter 
of these claims would have been obvious on the claim date to a person skilled In the art or 
science to which they pertain having regard to D1 in view of D2, 



Indeflntteness 

The claims are indefinite and do not comply with subsection 27{4) of the Patent Act 

Claim 15 describes a system for recognizing a wagerer comprising a wagering control system. 
It is unclear, however, precisely what a wagering control system is, what physical elements 
comprise the wagering host system, and how each physical element Is Interconnected to give 
the specified wagering functionality so that a person skilled In the field may be able to enable 
the invention. 

Claims 16 to 28 are each dependent on claim 15 and fall to overcome the objection made for 
that claim. 

Therefore, claims 15 to 28 are Indefinite and do not comply with subsection 27(4) of the Patent 
Act 



Other defects found 

A statement (n an application, such as found on page 1, lines 15 to 16 of the description section, 
which Incorporates by reference any other document, does not comply with subsection 81(1) of 
the Patent Rules. 

The application does not comply with section 79 of the Patent Rules. An application shall 
contain an abstract that provides technical infomnatlon by using a concise summary of the 
matter contained In the application. 
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Requisition of prior art cited in a foreign prosecution 

Under section 29 of the Patent Rules, the applicant is requisitioned to provide an (dentlfication 
of any prior art cited (and a copy of any non-patent prior art cited) tn the prosecution of 
con-esponding foreign applications, as well as any particulars of conflict, opposition, re- 
examination or similar proceedings. Identification of any prior art cited shall be done by refem'ng 
to application numbers, filing dates and, if granted, the patent numbers. Where a prior art 
document is not in either English or French, a translation of the document into English or French 
(preferably English) Is required. To satisfy this requisition, applicant should provide all the 
preceding Information or documents, or state reasons why any information or document Is 
unavailable or unl^nown. 

In view of the foregoing defects, the applicant is required, under subsection 30(2) of the Patent 
Rules, to amend the application in order to comply with the Patent Act and the Patent Rules or 
to provide arguments as to why the application does comply- 
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